The invention relates to the general field of telecommunications and to multimedia Internet protocol (IP) network architectures, such as network architectures using in particular the so-called “voice over IP” (VoIP) technology.
A preferred but non-limiting application of the invention lies in the context of multimedia IP core networks using the multimedia session initiation protocol (SIP) as defined by the Internet Engineering Task Force (IETF) standard and as described in particular in Document RFC 3261 entitled “SIP: session initiation protocol”, published in June 2002 by the IETF. The invention applies in particular to multimedia IP core networks relying on an IP multimedia subsystem (IMS) architecture as proposed by the third generation partnership project (3GPP) standard.
Nevertheless, it may also be used in association with other message IP core network architectures, such as for example proprietary architectures, using or not using the SIP protocol in order to set up multimedia sessions (i.e. voice, text, video, data, etc. sessions).
The invention relates more particularly to using a processor entity to process a message received from a first device and sent to a second device (such as a terminal or a server) managed by a multimedia IP core network, in the context of a multimedia communications service relying on a mechanism for automatically discovering the capabilities and the status of the remote party (in other words, in this context, of the second device).
In known manner, such an automatic discovery mechanism provides for the first device to send a specific message to the “remote” second device inviting it to declare in response to that message firstly its status (e.g. availability, busy, out of coverage, not registered, etc.), and secondly its capabilities, i.e. the services, protocols, and/or applications that it supports or uses.
In the description below, that specific message is referred to as a message “for discovering the capabilities and the status of the remote party” or as a message “for discovering the capabilities and the status of the second device”. One example of such a message in the SIP protocol is a message relying on the SIP OPTIONS method.
This automatic discovery mechanism is used in particular by the rich communication suite—enhanced (RCS-e) message service as described in the document entitled “RCS-e advanced communications: services and client specification”, Version 1.1, Apr. 8, 2011.
In known manner, the RCS-e standard enables two terminals that are registered with an IMS core network to set up communication via a circuit-switched network that is not connected to the IMS core network (e.g. via a global system for mobile communications network (GSM)), and then in parallel with or at the margin of that communication, to make use of additional message services known as “enriched communication” passing via a packet-switched network that is connected to the IMS core network, such as for example a service for transferring photos, an instant messaging service, a file sharing service, etc.
For this purpose, and in particular when creating a contact in the contacts list of a first terminal or when setting up a call between a first terminal and a second terminal, the RCS-e standard makes provision to use a mechanism enabling the first terminal automatically to discover the status and the RCS-e capabilities of the second terminal (and vice versa), based on using an SIP OPTIONS message.
The use of a mechanism for automatically discovering the status and the capabilities of the remote party may also be envisaged in the context of an after-sales service provided by a telecoms operator or by a service supplier, in order to obtain relevant information concerning the status and the capabilities of a device on which a maintenance operation is programmed or desired.
In accordance with the SIP protocol, any device receiving an SIP OPTIONS discovery message is required to respond thereto in transparent manner, by sending an appropriate response message to the device that sent the discovery message, which response message specifies its status and contains its capabilities.
Thus, for example, if the second device is available and compatible with the RCS-e service, it sends a 200 OK message to the first device, containing, in a “feature tag” field, the identifier of the RCS-e service, together with the identifiers of other services supported by the second device (via other features tags and/or session description protocol (SDP) sessions). The 200 OK response message also contains the SIP methods supported by the second device, etc.
It should be observed that, in accordance with the standard, an SIP OPTIONS message is received by the second device without the user of the second device being made aware of it. It is not specifically signaled to the user and it does not trigger any ringing of the second device or notification that the SIP OPTIONS message has been received.
Thus, the SIP standard nowadays makes it possible for any device to send an SIP OPTIONS message and discover, in entirely discrete manner, the status and/or the capabilities of a remote device, without the user of that remote device being informed that the discovery mechanism has been used and without leaving any trace of such use.
It can thus be understood that that mode of operation can lead to abuse. In particular, it can be feared that unprincipled economic players will send unwanted SIP OPTIONS messages in order to obtain information concerning the terminals of users, and in order to use such information for purely commercial purposes (e.g. reselling such information to commercial companies).
There therefore exists a need for a mechanism that provides protection against such abuse.